A memory controller may be a passive circuit that controls a main memory (e.g., Dynamic Random Access Memory (DRAM)). The memory controller may control a flow of data from/into the DRAM, and also may periodically “refresh” the DRAM. For the purpose of controlling data flow, the memory controller may include the requisite logic to read from the memory and/or write into the DRAM.
The source of commands associated with the abovementioned read/write processes may be a Central Processing Unit (CPU) request, a Direct Memory Access (DMA) request, a Graphics Processing Unit (GPU) request etc. These commands may require tough arbitration because, for example, to perform a read/write operation, a memory page may have to be activated/closed based on a conflict thereof. Selection may have to be done between the aforementioned command sources (or memory clients) as to which command (e.g., ACTIVATE, PRECHARGE) may have to be placed on a bus first. Thus, the memory controller may become logic intensive.
The logic intensiveness of the arbitration logic and the page management may pose a difficulty in meeting the logic requirements at a particular technology node (e.g., 90 nm). According to the Double Data Rate-2 (DDR2) DRAM specification standards defined by the JEDEC Solid-State Technology Association (hereinafter JEDEC), the maximum speed at which the DRAM memory clock may operate was 400 MHz, with a technology node of 90 nm fitting a certain number of logic levels within the 400 MHz. With the advent of the DDR3 DRAM specification defined by JEDEC, the maximum speed of operation of the DRAM memory clock changed to 800 MHz. This may afford very little width for timing closures. Therefore, the possibility of fitting all of the page management and arbitration into a single clock may be remote.
One way to overcome the abovementioned problem is to move to a technology node that may be faster than 90 nm (e.g., 65 nm, 45 nm, 40 nm). Even if the fast node were available, all the complex logic requirements may not fit into a single clock because of route delays being dominant. Another way is to pipeline commands over a number of clock cycles based on the timing requirements. This may compromise performance as latency may be increased.